home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 420 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  13.6 KB
  1. Subject: The Undigestable Digested
  2. Date: Sun, 12 Jun 1994 17:30:22 +0200 (MDT)
  3. From: Annius.Groenink@cwi.nl (Annius Groenink)
  4. X-Face: "E3Hm]k]&:,OEP<{D2ixJf>-9[qOGLebNa0&cQyFL-a~)kTM3&&I"gFw=fJ]K%1IduGjOE`
  5.  ZGu]&~G]QNGa7i/L!+#Xng<|+}HKYHj~5?fTInUEUh0$I1gBI7jrA!&_|e/pR1[cX:^xgJTPsrjA_9
  6.  m8Zli[|.-u{]+c1(6C7mL*m`/_J\>.{4!:g
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11.  
  12. Neil:
  13.  
  14. > I think the ST Book had a blue 'Atari' key, which meant certain keys with blue
  15. > figures on could be used as a numeric keypad... I don't know wether they work
  16. > the same way or not, but it is laid out exactly the same...
  17.  
  18. Ah.  A nice way to represent the num pad key combinations (in blue) in menus.
  19.  
  20. -------
  21.  
  22. Warwick:
  23.  
  24. > A MUCH safer technique is to use Shift-FULLER.  It also trains users to
  25. > look on the right-hand side for the SMALLER.  It's also very meaningful,
  26. > since the FULLER already means `Change Size', which is what iconification
  27. > is all about.
  28.  
  29. Makes sense.  I'll change my code.  Should this be part of the standard?
  30.  
  31. -------
  32.  
  33. Proposal v5:
  34.  
  35. >CTRL Home -              Move to top of page
  36. >Shift+CTRL Home -        Move to bottom of page
  37. >ClrHome -                Move to top of document
  38. >Shift+ClrHome -          Move to bottom of document
  39.  
  40. More standard is
  41.  
  42.    Control Uparrow        Move to top of page
  43.    Control Dnarrow        Move to btm of page
  44.    Shift Uparrow          Page up
  45.    Shift Dnarrow          Page dn
  46.  
  47. ------
  48.  
  49. Michael Nolte proposes to add Ctrl to home/shift home for top/bottom of document:
  50.  
  51. > - Safety. If you accidentally press ClrHome, you'll find back to where you
  52. >   were easier, if the cursor has only jumped to the top of the frame/page 
  53. >  instead of jumping to the top of the document. CTRL-ClrHome is harder  
  54. > to hit by accident.
  55.  
  56. This is much the same story as Control A being dangerous---an application should
  57. provide a way to jump back to the original position when a user hits HOME by
  58. accident.  (for example by placing a marker).  It is not the code that is dangerous,
  59. but the limitated safety measures (no airbag) of most applications.
  60.  
  61. ------
  62.  
  63. Stefan:
  64.  
  65. > What about standard key for fulling a window?
  66. >  I use: *
  67. > And for zooming the window contents?
  68. >  I use:
  69. >  + for zoom in, more details
  70. >  - for zoom out, fewer details
  71. >  0 for original zoom factor
  72.  
  73. Yes.  Pretty standard!  I proposed this earlier.  It should at least be implemented
  74. optionally,  as I've done in Edith.  It applies to practically any GEM application.
  75. (In Edith +/- means smaller/larger font).
  76.  
  77. -----
  78.  
  79. Warwick on Redo/Repeat
  80.  
  81. > VI users would propose CTRL-.
  82.  
  83. (and so would the few who have already got used to Edith Pro...)  Seriously,  Undo
  84. and Redo have 'do' in common,  so I really think having Shift Undo or Control Undo
  85. as redo is nice.  But we argued earlier that redo and do again is not the same!
  86. Redo is un-undo,  whereas for 'do it again',  no undo operation needs to have occurred.
  87. 'Do it again' after Undo could mean 'Undo the operation BEFORE the one just undone.'
  88. (if an application has multi-stage undo).
  89.  
  90. -----
  91.  
  92. Michel in reply to my HELP philosophy
  93.  
  94. > Why strictly ASCII files?  The main advantage of using a program like
  95. > ST-Guide is that you can have images, diagrams, boxes, circles, text
  96. > effects, and other features to make your online help presentable.  Since
  97. > it is an external program, it also does not add to the size of your
  98. > application.
  99.  
  100. The reason I want plain ASCII files is that it is then very easy to drag
  101. all the documents on your hard disk into a directory.  Write a short description
  102. of each file,  call the file containing the descriptions WHATIS (cf. Unix man)
  103. and the thing works!
  104.  
  105. > Er, what?  I'm not sure I follow this point.  Is there any particular
  106. > reason why you would not want your data files in the same directory
  107. > as your program?
  108.  
  109. Well...  I recently divided my HD into applications,  resources and user-specific
  110. data.  Of course,  on a multi-user system,  this would always be the case.
  111. And yes,  I feel happier if all help files are in the same hierarchy,  apart from
  112. the applications.
  113.  
  114. -----
  115.  
  116. Michel:
  117.  
  118. > Ofir, I just noticed; there is no "abandon" key in the standard.  The
  119. > standard (used by all programs I have seen) is Control-H.  Since that
  120. > is not used in the proposal, could we add this key?
  121.  
  122. Control H was originally in a note saying:  Atari suggest control H for
  123. Replace (as in swap text block and selection fragmentwise).  This is a very
  124. good way of looking at search and replace.  It should remain available
  125. optionally.  And since we're talking about UNDO anyway,  what about:
  126.  
  127.    Undo        Undo
  128.    Sh Undo     Redo                 (shift being a modifier that sometimes
  129.                                      means `in the opposite direction')
  130.    Ctl Undo    Undo the whole lot   (i.e.  Abandon or Restore)
  131.  
  132. Ofir replies:
  133.  
  134. > There is, although I put it in the wrong place.
  135. > 
  136. > CTRL D -                 Abandon Window (iconify or place in menu)
  137. > 
  138. > as suggested by Wilfried Behne.
  139.  
  140. That's not the same kind of 'abandon'...
  141.  
  142.  
  143.  
  144. Michel [I was over-expounding on active/top windows...]
  145.  
  146. > Annius, I feel that this is too specific.  Making a distiction between
  147. > the top window and the active window only applies to Edith.  No other
  148. > program I have seen (ever) have made this distiction.  Making it a part
  149. > of the standard would be too complex, when we are trying to keep things
  150. > simple.
  151.  
  152. You're probably right.  I should find my own way of doing this within the
  153. standard as it is proposed.  However,  there are a few programs that support
  154. key input into background windows  (ASCREEN is one,  and I've got two other
  155. German goodies on my disk but I forgot which ones).
  156.  
  157. -----
  158.  
  159. Timothy ``my little finger'' Miller writes:
  160.  
  161. > The block=big-cursor method seems the most natural to me, and one of the 
  162. > reasons I like it is that the cursor commands are heterogenious, where 
  163. > the same commands that work on text work on blocks just the same, and 
  164. > another reason I like it is that it takes a lot fewer total keypresses to 
  165. > deal with
  166.  
  167. ...and a lot fewer total keypresses to unintentionally get rid of your documents!
  168.  
  169. -----
  170.  
  171. Warwick in the ``what should preceed what'' discussion:
  172.  
  173. > action:key:
  174. > 
  175. >     *Dialog*.Confirm.Key: Return
  176. >     *Dialog*.Confirm.Colour: Green
  177. > 
  178. > 
  179. > key:action:
  180. >     Dialog*Key.Return: Confirm
  181. >     Dialog*Colour.Green: Confirm
  182. >     # huh?
  183.  
  184. I'd say there are sections
  185.  
  186.    'key'       maps a key code to a value (an action)
  187.    'colour'    maps a user interface component to a value (a colour)
  188.  
  189. hence
  190.  
  191.          Dialog*Key.Return:      Confirm
  192.          Dialog*Colour.Confirm:  Green
  193.          # hm.
  194.  
  195. I think I'll stay low level for a while.  Things are getting ever more complicated...
  196. I think at this point,  reading the rest of Warwick's story,  I agree with
  197. 'action-key'.  My original thought was 'key-action' would be easier to implement
  198. (an array 'indexed' by the keys for quick access to their corresponding actions)
  199.  
  200. -----
  201.  
  202. Gerd:
  203.  
  204. > When we talk about text blocks, we should have in mind, that text blocks
  205. > can be discontinuous!
  206.  
  207. > In the case of block operations: Have discontinuous blocks in mind.
  208.  
  209. I am!  Actually,  I've got one in my window right now!
  210.  
  211. -----
  212.  
  213. Timothy 'Control-A' Miller replies to someone arguing about ShCtl S <-> Ctl M
  214. (it takes 10 minutes to get used to ShCtl S)
  215.  
  216. > Ah, but you use the opposite logic when saying why we should keep 
  217. > Ctrl-A.  If they'll take 10 minutes to get used to the new standard, then 
  218. > they'll take 10 minutes to learn something other than ctrl-a, and they 
  219. > won't be bothered by it since ctrl-a will do absolutely nothing.
  220.  
  221. I *actually* agree here!  Small sacrifice to swap ^A and Shift^A!
  222.  
  223. -----
  224.  
  225. Tim:
  226.  
  227. > But I've never seen a text editor (I haven't seen the one you mention) 
  228. > that did discontinuous blocks.  Sounds like it would be a pain to deal 
  229. > with... I'd need to keep track of ANOTHER linked-list in memory.  
  230. > <grumble>  Memory management....
  231.  
  232. Papyrus is a word  processor, not an editor.  Edith  (which I wrote  and
  233. ZFC distributes) is an Editor which does discontinuous blocks.  BTW,   I
  234. don't use a  linked list  at all,   I simply use  an array  and a  smart
  235. re-allocation  scheme.   But  I  agree,   discontinuous  blocks  is  not
  236. something you can properly  do in a  few weeks...  It  took me years  to
  237. implement a proper mechanism.
  238.  
  239. > >You're right. How about CTRL+<, CTRL+>, CTRL+SHIFT+< and CTRL+SHIFT+>?
  240. > 
  241. > I disagree... Ctrl-< is the same thing as ctrl-,  This gets icky.  I 
  242.  
  243. And besides,  on a German  keyboard Control + < is  the same as Shift  +
  244. Control + > as '<' and '>' are on the same key!!
  245.  
  246. > Don't ever use any software that uses Ctrl-A for Select-All
  247. > Don't ever use any software that uses Shift-Backspace to delete a line.
  248. > Unusual tagline, isn't it?
  249.  
  250. EXCEPT software where these combinations are harmless.  I have to  thank
  251. Timothy sincerely though,  as I dicovered and fixed a problem concerning
  252. Shift Backspace in Edith.   You can now safely  hit shift + backspace  5
  253. times (by accident) without losing the  original contents of the  line. 
  254. (this used to be only  once.) Simply hit UNDO and  on you go.  I'll  add
  255. Timothy to the 'acknowledgements'.
  256.  
  257. -----
  258.  
  259. Evan K. Langlois:
  260.  
  261. > the traffic, but I recently saw some sort of suggestion about replacing
  262. > the keyboard table!  This table is system wide.  Replacing it is suicide
  263. > for MultiTOS.  
  264.  
  265. MultiTOS and suicide are synonyms anyway...
  266.  
  267. > There is a little trick you can do to get all 16 colors in any dialog and
  268. > have it perfectly readable in ALL modes.  And it looks fine in mono too!
  269. > What you do is set the dialog background color to the opposite color
  270. > that you want it, now set the SELECTED bit
  271.  
  272. Ah!  The same as the '!!' trick in C...  Smart,  but a bit cumbersome...
  273.  
  274. -----
  275.  
  276. Michel:
  277.  
  278. > Ofir, I am not sure that you understand what I meant.  As written, the
  279. > above keyboard shortcut implies that the window should be iconified if
  280. > the key is pressed.  I mean we need a key that causes any changes you
  281. > have made to your document/whatever to be thrown away.  Everyone,
  282. > even Atari, use Control+H for this...
  283.  
  284. Not true.   The latest  Atari  guidelines specify  ^H for  Replace  (not
  285. search AND replace,  but just replace.  Control + Undo would be a better
  286. choice for this (undo all).
  287.  
  288. -----
  289.  
  290. Julian Reschke:
  291.  
  292. > I thought that the idea of his proposal is more POSIX-like. Not to *change*
  293. > existing practice, but to document it. I doubt that any major developer
  294. > will change his existing code just to make the readers of this list happy.
  295.  
  296. I think you're right.   But the proposal doesn't  change all that  much,
  297. except perhaps  for ShiftControl  S.   That's why  I suggested  to  keep
  298. Control + M as well  as ShiftControl S.  (I saw  that Ofir has said  the
  299. same somewhere else).  You'll see that in the end, Sh^S is the code that
  300. will survive,   as  it is  much  easier to  remember.   It is  also  the
  301. standard on other platforms than Atari.
  302.  
  303. Julian:  do  you know  a 'POSIX' like  *explanation* for  the fact  that
  304. Control M is used as a shortcut for Save As...?
  305.  
  306. ------
  307.  
  308. -- Barry S. Munro -----------------------------------:-(
  309.  
  310. > If the .SYS idea is to be implemented then there are no problems at all 
  311. > with CTRL+A as it could be changed using one line in this file!
  312.  
  313. And any  program that  bothers  about our  standard will  probably  also
  314. bother to implement  the DEFAULTS.INF specification!  So whatever we  do
  315. with control + A,  any program  whose author has read our proposal  will
  316. provide a way out for Timothy Miller.
  317.  
  318. -----
  319.  
  320. Michael Nolte:
  321.  
  322. > I want Sh-CTRL-V as "Paste from...", because you can do it easily with one
  323. > hand. For "Shift-CTRL-I" you need two hands (or very long fingers).
  324.  
  325. Weird argument...  Is  "Paste from..." something you  do *so*  regularly
  326. that you want to be able to do it with one hand?
  327.  
  328. -----
  329.  
  330. Ofir:
  331.  
  332. > Even the so called German standard is not that well defined - CTRL+I in
  333. > Everest selects a word, in Kobold it shows Object Info, in Papyrus it does
  334. > something else (I forget what) and the list goes on.
  335.  
  336. Good point.  as to ^I:  in a standard ^I for show info would be the most
  337. general we can think  of.  If you  make a table  counting the number  of
  338. programs that use ^I for each different purpose,  you'd find that  'Show
  339. Info' gets most points.  A  good extra note in  the guidelines would  be
  340. that if ever a programmer decides to use a keycode from the proposal for
  341. something DIFFERENT,  s/he  should watch  out that it  is not  dangerous
  342. when  a  user  assumes  the  standard   meaning  (as  set  out  in   the
  343. proposal) and simply hits the key without RTMF.
  344.  
  345. -----
  346.  
  347. Rick Flashman (Gribnif)
  348.  
  349. > (because it makes more sense), we would have a substancial revolt among 
  350. > our users (you should hear how many complaints our beta testers gave us 
  351. > as we tried to change our close window from the original NeoDesk 
  352. > CONTROL-W to the more accepted Alt-Esc).
  353.  
  354. Well that sure is funny.  We were just discussing changing CYCLE WINDOWS
  355. (Control W) to the more accepted Alt-Esc!  :-)  Does this mean that  the
  356. confusion between cycling and  closing windows is something  universal, 
  357. that goes beyond just the Atari world? :-?
  358.  
  359. -----
  360.  
  361. Ofir says control A is not open for discussion;  Tim Miller replies:
  362.  
  363. > I think is most certainly IS open for discussion.  The fact that is has 
  364. > been brought up and demonstrated to be potentially hazzardous is enough 
  365. > to make it important.
  366.  
  367. Well it HAS been discussed for more than a week now and the results  are
  368. clear.  Control A is there to stay (although I'd settle for adding shift
  369. and having control A for deselect all).  Let's close the discussion Now.
  370.  
  371.  
  372.  
  373. ------
  374. Is anyone actually reading upto this point?
  375.  
  376. regards,
  377. -- 
  378. Annius V. Groenink | E-mail: avg@cwi.nl      |  Private & ZFC:
  379. CWI, Kruislaan 413 | Room:   M233            |  P.O. Box 12079
  380. 1098 SJ Amsterdam  | Ext:    4077            |  NL 1100 AB Amsterdam 
  381. Netherland         | Phone:  +31 20 592 4077 |  Phone: +31 20 695 9901
  382.